Network service providers typically deploy one or more servers to manage authentication, authorization, and accounting (AAA) functionality for networks that offer services to one or more subscribers. A protocol commonly used by the servers to communicate with clients is the Remote Authentication Dial In User Service (RADIUS) protocol. The RADIUS protocol is described in Carl Rigney et al., “Remote Authentication Dial In User Server (RADIUS),” Network Working Group of the Internet Engineering Task Force (IETF), Request for Comments 2865, June 2000, which is incorporated by reference herein in its entirety (referred to hereinafter as “RFC 2865”). An extension to the RADIUS protocol commonly used to initiate a change of authorization (CoA) is the Dynamic Authorization Extensions to RADIUS. The Dynamic Authorization Extensions to RADIUS is described in Murtaza Chiba et al., “Dynamic Authorization Extensions to Remote Authentication Dial In User Server (RADIUS),” Network Working Group of the Internet Engineering Task Force (IETF), Request for Comments 5176, January 2008, which is incorporated by reference herein in its entirety (referred to hereinafter as “RFC 5176”).
During a CoA for a subscriber that has initially authenticated and authorized, the server may provision one or more services using the RADIUS protocol. To provision the services, the server may provide service configuration data (which may also be referred to as “change of authorization data,” “CoA data,” or simply “authorization data”). A router positioned between the subscriber and the server may provision the services using the service configuration data, thereby allowing the subscriber to utilize the service to access the service provider network.
In some instances, the subscriber may have subscribed to a large number of services that results in the server having to deliver service configuration data that exceeds limits set by the RADIUS protocol, for example, a maximum packet size of 4096 bytes. To send all of the service configuration data, the server may fragment the service configuration data into multiple portions sending each portion via a different RADIUS message. In order to receive the next RADIUS message with the next portion of the service configuration data, the router may process each portion of the service configuration data individually and confirm successful provisioning of the services specified by the portion of the service configuration data sent via the current RADIUS message.
The router may therefore iterate between provisioning some subset of the services specified by the portion of the service configuration data for a CoA in the current RADIUS message and receiving the next RADIUS message until all of the service configuration data has been received and applied. Such iteration may be inefficient, as the router may transition between a relatively complex provisioning process and waiting to receive the next RADIUS message.